Description

Aligns the TabsHost public API with RFC-1028's request/state distinction.

The prop currently named navState carries a request for a state change — not the state itself. The resulting state is delivered back to JS through the OnTabSelected event. Today both sides expose a field called provenance, but they refer to different things:

• on the request: provenance of the state the request was derived from (i.e. the JS-side base),
• on the event payload: provenance of the resulting state after the transition.

Renaming the prop and field makes this distinction explicit at the API surface and prevents downstream consumers from conflating the two.

Most other RFC-1028 deliverables are already implemented (OnTabSelected/OnTabSelectionRejected/OnTabSelectionPrevented, isNativeAction, rejectStaleNavStateUpdates, the prevention event). This PR is the remaining rename pass.

No behavior change.

Changes

• Public TS:
  • type TabsHostNavState → TabsHostNavStateRequest
  • field provenance → baseProvenance on the request type
  • prop navState → navStateRequest on TabsHostPropsBase
  • re-export updated in src/components/tabs/index.ts
• Codegen specs (Android + iOS): same prop/field rename. The C++ Props struct regenerates automatically on next codegen run.
• Native binding boundary:
  • Android: setNavStateRequest override on the ViewManager, parses selectedScreenKey + baseProvenance from the ReadableMap.
  • iOS: prop access in RNSTabsHostComponentView::updateProps.
• Internal native state types are kept untouched — they model state, not requests:
  • Kotlin TabsNavState (data class)
  • ObjC RNSTabsNavigationState
  • TabSelectOp.navState payload (the op models a container-level state update, not a JS request)
• Internal members holding the most recent JS request renamed for clarity:
  • Android: jsNavState → jsNavStateRequest, updateJSNavState → updateJSNavStateRequest
  • iOS: _jsNavState → _jsNavStateRequest, @property navState → @property navStateRequest
• Apps consumer (apps/.../TabsContainer.{tsx,types.tsx}) updated in lockstep so the workspace stays green; helper hook renamed useTabsHostNavState → useTabsHostNavStateRequest.

Test plan

This is a pure rename — no behavior change is introduced. Verification focused on build/type integrity and a manual smoke test in FabricExample:

• yarn check-types (library) — passes.
• yarn check-types in apps/ — only pre-existing, unrelated errors remain (no errors mention navState/TabsHostNavState after the rename).
• Android: full rebuild of FabricExample — codegen regenerates RNSTabsHostAndroidManagerInterface.setNavStateRequest(...) and the RNSTabsHostAndroidNavStateRequestStruct C++ struct; the Kotlin override compiles against the new signature.
• iOS: pod install + build of FabricExample — codegen produces the renamed C++ Props member; the ObjC++ side reads newComponentProps.navStateRequest.{selectedScreenKey,baseProvenance}.
• Manual smoke test in FabricExample Tabs example: drive tab changes from JS (programmatic, via the apps' TabsContainer) and from native (tab bar tap). Confirm tab selection works on both platforms and OnTabSelected events still fire as expected.

Reviewers may want to focus on:

• src/components/tabs/host/TabsHost.types.ts — public type shape
• both codegen specs in src/fabric/tabs/
• the boundary conversion in TabsHostViewManager.kt::setNavStateRequest and RNSTabsHostComponentView.mm::updateProps (request's baseProvenance is fed in as the constructor's provenance: arg on the internal state types — by design)

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• For API changes, updated relevant public types.
• Ensured that CI passes